Esiliidese mandaadihaldus: Sügavuti parooli- ja identiteedi API-dest

Pidevalt areneval veebiarenduse maastikul jääb sisselogimisvorm fundamentaalseks, kuid sageli masendavaks kasutajainteraktsiooniks. Aastakümneid on lihtne kasutajanime ja parooli kombinatsioon olnud väravavahiks meie digitaalsetesse eludesse. See traditsiooniline lähenemine on aga täis väljakutseid: parooliväsimus, nõrkadest või korduvkasutatud mandaatidest tulenevad turvaaugud ja kohmakas kasutajakogemus, mis võib viia kõrge põrkemäärani. Arendajatena navigeerime pidevalt kindla turvalisuse ja sujuva kasutajateekonna vahelisel õrnal tasakaalul.

Õnneks on veebiplatvorm oluliselt arenenud. Kaasaegsetes brauserites on nüüd võimas komplekt API-sid, mis on loodud spetsiaalselt nende autentimisprobleemide lahendamiseks. Need tööriistad, mis koonduvad ühisnimetaja Mandaadihaldus (Credential Management) alla, võimaldavad meil luua registreerimis- ja sisselogimiskogemusi, mis ei ole mitte ainult turvalisemad, vaid ka lõppkasutaja jaoks märkimisväärselt lihtsamad. See artikkel on põhjalik juhend esiliidese arendajatele nende API-de kasutamiseks – alates aluseks olevast Mandaadihalduse API-st kuni paroolivaba tulevikuni WebAuthn-iga ja privaatsust säilitava Föderaalse mandaadihalduse (FedCM) maailmani.

Vana kaardivägi: Traditsioonilise vormipõhise autentimise väljakutsed

Enne kaasaegsetesse lahendustesse süvenemist on oluline mõista probleeme, mida need lahendavad. Klassikaline <form> e-posti ja parooli sisenditega on veebi teeninud aastaid, kuid selle piirangud on üha ilmsemad maailmas, kus turvaohud ja kasutajate ootused on kõrgenenud.

• Halb kasutajakogemus (UX): Kasutajad peavad kümnete teenuste jaoks meeles pidama unikaalseid ja keerukaid paroole. See viib mandaatide unustamiseni, mille tulemuseks on masendavad parooli lähtestamise protsessid. Mobiilseadmetes on keerukate paroolide sisestamine veelgi tülikam.
• Turvariskid: Paroolide keerukusega toimetulekuks kasutavad kasutajad sageli ebaturvalisi praktikaid, nagu lihtsate, kergesti äraarvatavate paroolide kasutamine, sama parooli korduvkasutamine mitmel saidil või nende üleskirjutamine. See muudab nad haavatavaks mandaaditäitematerjali rünnete (credential stuffing attacks) suhtes, kus ründajad kasutavad varastatud mandaatide loendeid, et saada volitamata juurdepääs teistele teenustele.
• Andmepüügi haavatavused: Isegi taiplikke kasutajaid saab petta keerukate andmepüügisaitidega, mis jäljendavad seaduslikke sisselogimislehti, et nende mandaate varastada. Traditsioonilised paroolid pakuvad selle vastu vähe või üldse mitte mingit kaitset.
• Suur arenduskulu: Turvaliste autentimisvoogude nullist ülesehitamine on keeruline. Arendajad peavad tegelema paroolide räsimise ja soolamisega, rakendama mitmefaktorilist autentimist (MFA), haldama parooli lähtestamise märke ja kaitsma erinevate rünnete, näiteks toore jõu (brute-force) ja ajastusrünnete eest.

Need väljakutsed rõhutavad selget vajadust parema viisi järele – süsteemi järele, kus brauser ja operatsioonisüsteem saaksid tegutseda usaldusväärsete vahendajatena, lihtsustades protsessi kasutaja jaoks ja tugevdades samal ajal rakenduse turvalisust.

Kaasaegne lahendus: Mandaadihalduse API

Mandaadihalduse API (Credential Management API) on kaasaegse esiliidese autentimise nurgakivi. See pakub standardiseeritud, programmilist liidest veebisaitidele brauseri mandaadihoidlaga suhtlemiseks. See hoidla võib olla brauseri sisseehitatud paroolihaldur või isegi ühendatud operatsioonisüsteemi tasemel varahoidla. Selle asemel, et tugineda ainult HTML-vormide automaatse täitmise heuristikale, võimaldab see API arendajatel otse kasutaja mandaate küsida, luua ja salvestada.

API on kättesaadav JavaScripti objekti navigator.credentials kaudu ja see keerleb kolme peamise meetodi ümber: get(), create() ja store().

Mandaadihalduse API peamised eelised

• Ühe puutega sisselogimine: Naasvate kasutajate jaoks võimaldab API peaaegu hetkelist sisselogimiskogemust. Brauser saab kasutajale pakkuda salvestatud konto valimist ning ühe puudutuse või klõpsuga antakse mandaadid veebisaidile.
• Sujuvam registreerumine: Registreerimise ajal aitab API, täites automaatselt teadaolevat teavet ja pakkudes pärast edukat registreerumist sujuvalt kasutajale uute mandaatide salvestamist.
• Tugi mitmele mandaaditüübile: See on võib-olla selle kõige võimsam funktsioon. API on loodud laiendatavaks, toetades mitte ainult traditsioonilisi paroole (PasswordCredential), vaid ka föderaalseid identiteete (FederatedCredential) ja WebAuthn-i kasutatavaid avaliku võtme mandaate (PublicKeyCredential).
• Täiustatud turvalisus: Vahendades suhtlust, aitab brauser leevendada turvariske. Näiteks tagab see, et mandaadid on kättesaadavad ainult sellele päritolule (domeenile), mille jaoks need salvestati, pakkudes loomupärast kaitset paljude andmepüügirünnete vastu.

Praktiline rakendamine: Kasutajate sisselogimine `navigator.credentials.get()` abil

Meetodit get() kasutatakse kasutaja mandaatide hankimiseks sisselogimiseks. Saate määrata, milliseid mandaaditüüpe teie rakendus toetab.

Kujutage ette, et kasutaja jõuab teie sisselogimislehele. Selle asemel, et ta peaks midagi sisestama, saate kohe kontrollida, kas tal on salvestatud mandaat.

            async function handleSignIn() {
  try {
    // Check if the API is available
    if (!navigator.credentials) {
      console.log('Credential Management API not supported.');
      // Fallback to showing the traditional form
      return;
    }

    const cred = await navigator.credentials.get({
      // We are requesting a password-based credential
      password: true,
      // You can also request other types, which we'll cover later
    });

    if (cred) {
      // A credential was selected by the user
      console.log('Credential received:', cred);
      // Now, send the credential to your server for verification
      await serverLogin(cred.id, cred.password);
    } else {
      // The user dismissed the prompt or has no saved credentials
      console.log('No credential selected.');
    }
  } catch (err) {
    console.error('Error getting credential:', err);
    // Handle errors, e.g., show the traditional form
  }
}

async function serverLogin(username, password) {
  // This is a mock function. In a real app, you would send
  // this to your backend via a POST request.
  const response = await fetch('/api/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username, password }),
  });

  if (response.ok) {
    window.location.href = '/dashboard'; // Redirect on success
  } else {
    // Handle login failure
    console.error('Login failed on the server.');
  }
}

            

              
                Copy
              
            
          

Selles näites käivitab navigator.credentials.get({ password: true }) kutsumine brauseri, et kuvada natiivne kasutajaliides (sageli kontovalija), mis loetleb kõik praeguse domeeni jaoks salvestatud mandaadid. Kui kasutaja valib ühe, lahendatakse lubadus PasswordCredential objektiga, mis sisaldab id (kasutajanimi) ja password (parool). Teie rakendus saab seejärel saata selle teabe serverisse autentimisprotsessi lõpuleviimiseks.

Praktiline rakendamine: Mandaatide salvestamine `navigator.credentials.store()` abil

Pärast seda, kui kasutaja on edukalt registreerunud või sisse loginud traditsioonilise vormi abil (võib-olla varuvariandina), peaksite pakkuma tema mandaatide salvestamist tulevaseks kasutamiseks. Meetod store() muudab selle sujuvaks.

            async function handleSuccessfulSignUp(username, password) {
  try {
    // Create a new PasswordCredential object
    const newCredential = new PasswordCredential({
      id: username,
      password: password,
      name: 'User display name' // Optional: for the account chooser
    });

    // Store the credential
    await navigator.credentials.store(newCredential);
    console.log('Credential stored successfully!');

    // Proceed to redirect the user or update the UI
    window.location.href = '/welcome';
  } catch (err) {
    console.error('Error storing credential:', err);
  }
}

            

              
                Copy
              
            
          

Kui see kood käivitub, esitab brauser tagasihoidliku viipa, küsides kasutajalt, kas ta soovib parooli salvestada. See on palju parem kasutajakogemus kui loota brauseri mõnikord ettearvamatule heuristikale, et tuvastada edukas sisselogimine ja pakkuda parooli salvestamist.

Järgmine piir: Paroolivaba autentimine WebAuthn-i ja pääsmevõtmetega

Kuigi Mandaadihalduse API parandab oluliselt paroolidega seotud kogemust, on paljude jaoks lõppeesmärk paroolidest täielikult loobuda. Siin tulebki mängu Veebiautentimise API (WebAuthn). WebAuthn on W3C standard, mis võimaldab paroolivaba, andmepüügikindlat autentimist, kasutades avaliku võtme krüptograafiat.

Võib-olla olete hiljuti kuulnud terminit Pääsmevõtmed (Passkeys). Pääsmevõtmed on WebAuthn-i taga oleva standardi kasutajasõbralik rakendus. Pääsmevõti on digitaalne mandaat, mida hoitakse kasutaja seadmes (näiteks telefonis, arvutis või riistvaralises turvavõtmes). Seda kasutatakse veebisaitidele ja rakendustesse sisselogimiseks ilma paroolita. Need sünkroonitakse sageli kasutaja seadmete vahel pilveteenuste kaudu (nagu iCloud Keychain või Google Password Manager), muutes need uskumatult mugavaks.

Miks on WebAuthn turvalisuse seisukohalt murranguline

• Andmepüügikindel: Pääsmevõti on krüptograafiliselt seotud veebisaidi päritoluga, kus see loodi. See tähendab, et domeeni my-bank.com jaoks loodud pääsmevõtit ei saa kasutada andmepüügisaidile nagu my-bank-login.com sisselogimiseks. Brauser lihtsalt ei luba seda.
• Jagatud saladusi pole: WebAuthn-iga genereerib kasutaja seade avaliku/privaatse võtmepaari. Privaatne võti ei lahku kunagi kasutaja turvalisest seadmest (autentikaatorist). Serverisse saadetakse ainult avalik võti. Isegi kui teie serveri andmebaasi murtakse sisse, ei leia ründajad varastamiseks paroole.
• Tugev mitmefaktoriline autentimine: Pääsmevõti ühendab olemuslikult selle, mis kasutajal on (seade privaatse võtmega) ja kes kasutaja on (tema sõrmejälg/nägu) või mida ta teab (tema seadme PIN-kood). See rahuldab sageli MFA nõuded ühes lihtsas sammus.

WebAuthn-i voog Mandaadihalduse API kaudu

WebAuthn-i hallatakse samuti navigator.credentials objekti kaudu, kasutades PublicKeyCredential tüüpi. Protsess hõlmab kahte peamist etappi: registreerimine ja autentimine.

1. Registreerimine (Pääsmevõtme loomine)

See on lihtsustatud ülevaade. Tegelik rakendamine nõuab hoolikat krüptograafiliste väljakutsete käsitlemist serveripoolel.

1. Klient taotleb registreerimist: Kasutaja annab märku, et soovib luua pääsmevõtme.
2. Server saadab väljakutse: Teie server genereerib unikaalse, juhusliku väljakutse ja mõned konfiguratsioonivalikud (objekti publicKeyCreationOptions).
3. Klient kutsub välja `navigator.credentials.create()`: Teie esiliidese kood edastab serverist saadud valikud sellele meetodile.

            const creationOptions = await fetch('/api/webauthn/register-options').then(r => r.json());

// Important: The server-generated challenge must be decoded from Base64URL to a BufferSource
creationOptions.challenge = bufferDecode(creationOptions.challenge);
creationOptions.user.id = bufferDecode(creationations.user.id);

const credential = await navigator.credentials.create({ publicKey: creationOptions });

            

              
                Copy
              
            
          

4. Kasutaja kinnitab: Brauser/OS palub kasutajal luua pääsmevõtme, kasutades oma seadme autentikaatorit (nt Face ID, Windows Hello või sõrmejäljeskaneerimine). Autentikaator loob uue avaliku/privaatse võtmepaari.
5. Klient saadab avaliku võtme serverisse: Tulemuseks olev mandaat, mis sisaldab uut avalikku võtit ja allkirjastatud tõendit, saadetakse tagasi teie serverisse kontrollimiseks ja salvestamiseks.

2. Autentimine (Pääsmevõtmega sisselogimine)

1. Klient taotleb sisselogimist: Kasutaja soovib oma pääsmevõtmega sisse logida.
2. Server saadab väljakutse: Teie server genereerib uue juhusliku väljakutse ja saadab selle kliendile (objekti publicKeyRequestOptions sees).
3. Klient kutsub välja `navigator.credentials.get()`: Seekord kasutate publicKey valikut.

            const requestOptions = await fetch('/api/webauthn/login-options').then(r => r.json());
requestOptions.challenge = bufferDecode(requestOptions.challenge);

const credential = await navigator.credentials.get({ publicKey: requestOptions });

            

              
                Copy
              
            
          

4. Kasutaja kinnitab: Kasutaja autendib end oma seadmega. Seadme autentikaator kasutab salvestatud privaatvõtit serverist saadud väljakutse allkirjastamiseks.
5. Klient saadab kinnituse serverisse: Allkirjastatud väljakutse (nimetatakse kinnituseks) saadetakse tagasi teie serverisse. Server kontrollib allkirja, kasutades salvestatud avalikku võtit. Kui see on kehtiv, logitakse kasutaja sisse.

Märkus: Toores WebAuthn API on märkimisväärselt keerukas, eriti andmete kodeerimise/dekodeerimise osas (nagu ArrayBufferid ja Base64URL). On tungivalt soovitatav kasutada läbiproovitud teeki, nagu SimpleWebAuthn, või teenusepakkujat, et käsitleda madala taseme detaile nii kliendi- kui ka serveripoolel.

Privaatsus ennekõike: Föderaalne mandaadihaldus (FedCM)

Aastaid on "Logi sisse Google'i/Facebooki/GitHubiga" olnud populaarne viis registreerimishõõrdumise vähendamiseks. Seda mudelit nimetatakse Föderaalseks identiteediks. Ajalooliselt tugines see suuresti mehhanismidele nagu ümbersuunamised, hüpikaknad ja kolmandate osapoolte küpsised sisselogimisstaatuse jälgimiseks saitide vahel. Kuna brauserid liiguvad kolmandate osapoolte küpsiste järkjärgulise kaotamise suunas kasutajate privaatsuse parandamiseks, on need traditsioonilised vood purunemise ohus.

Föderaalse mandaadihalduse API (FedCM) on uus ettepanek, mis on loodud föderaalse identiteedi kasutusjuhtude toetamiseks privaatsust säilitaval viisil, ilma kolmandate osapoolte küpsistele tuginemata.

FedCM-i peamised eesmärgid

• Säilitada föderaalsed sisselogimised: Lubada kasutajatel jätkata oma eelistatud identiteedipakkujate (IdP) kasutamist, et hõlpsasti sisse logida sõltuvatesse osapooltesse (RP, teie veebisait).
• Parandada privaatsust: Vältida IdP-de passiivset kasutajate jälgimist veebis ilma nende selgesõnalise nõusolekuta.
• Parandada kasutajakogemust ja turvalisust: Pakkuda brauseri vahendatud, standardiseeritud kasutajaliidest föderaalseteks sisselogimisteks, andes kasutajatele rohkem läbipaistvust ja kontrolli jagatavate andmete üle. See aitab ka vältida kasutajaliidesel põhinevaid andmepüügirünnakuid.

Kuidas FedCM töötab (üldisel tasemel)

FedCM-iga korraldab brauser ise sisselogimisvoo, toimides usaldusväärse vahendajana teie saidi (RP) ja identiteedipakkuja (IdP) vahel.

1. RP taotleb mandaati: Teie veebisait kutsub välja navigator.credentials.get(), seekord määrates federated pakkuja.

            async function handleFedCMLogin() {
  try {
    const cred = await navigator.credentials.get({
      federated: {
        providers: ['https://accounts.google.com', 'https://facebook.com'], // Example IdPs
        // The browser will look for a well-known manifest file on these domains
      }
    });

    // If successful, the credential object contains a token
    if (cred) {
      console.log('Received token:', cred.token);
      // Send the token to your server for validation and login
      await serverLoginWithToken(cred.token, cred.provider);
    }
  } catch (err) {
    console.error('FedCM Error:', err);
  }
}

            

              
                Copy
              
            
          

2. Brauser hangib manifestid: Brauser teeb liivakastis päringuid failile /.well-known/web-identity IdP domeenis. See fail annab brauserile teada, kust leida vajalikud lõpp-punktid kontode loendite hankimiseks ja märkide väljastamiseks.
3. Brauser kuvab kontovalija: Kui kasutaja on IdP-sse sisse logitud, kuvab brauser oma natiivse kasutajaliidese (nt rippmenüü ekraani paremas ülanurgas), mis näitab kasutaja saadaolevaid kontosid. RP lehe sisu ei varjata kunagi.
4. Kasutaja annab nõusoleku: Kasutaja valib konto ja nõustub sisselogimisega.
5. Brauser hangib märgi: Brauser teeb viimase päringu IdP märgi lõpp-punkti, et saada ID-märk.
6. RP saab märgi: Lubadus get()-st lahendatakse, tagastades FederatedCredential objekti, mis sisaldab märki. Teie veebisait saadab selle märgi oma taustaprogrammi, mis peab selle enne kasutajale seansi loomist IdP-ga valideerima.

FedCM on endiselt suhteliselt uus API ja brauserite tugi areneb, kuid see esindab veebis kolmandate osapoolte sisselogimiste tulevikusuunda.

Ühtne strateegia: Autentimise progressiivne täiustamine

Kuna saadaval on kolm erinevat tüüpi mandaate, siis kuidas peaksite oma esiliidese koodi struktureerima? Parim lähenemine on progressiivne täiustamine. Peaksite püüdma pakkuda võimalikult kaasaegset ja turvalist kogemust, pakkudes samal ajal vajadusel sujuvalt tagavaralahendusi vanematele meetoditele.

Mandaadihalduse API on selleks loodud. Saate taotleda kõiki toetatud mandaaditüüpe ühe get() väljakutsega ning brauser prioritiseerib ja esitab kasutajale parima valiku.

Soovitatav autentimisvoog

1. Eelistage pääsmevõtmeid (kui on saadaval): Kõige turvalisema ja sujuvama kogemuse saamiseks kontrollige kõigepealt, kas kasutajal on pääsmevõti. Saate kasutada PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() funktsiooni tuvastamiseks, et tingimuslikult kuvada nuppu "Logi sisse pääsmevõtmega".
2. Kasutage ühtset `get()` väljakutset: Tehke üksainus kutse navigator.credentials.get()-le, mis sisaldab valikuid publicKey, password ja _potentsiaalselt_ federated jaoks. Brauser on selles osas tark; näiteks ei kuva see parooliviipa, kui pääsmevõti on saadaval ja eelistatud.
3. Käsitlege tagastatud mandaati: Kontrollige tagastatud mandaadi objekti tüüpi, kasutades instanceof, ja töödelge seda vastavalt.
4. Sujuv tagavaralahendus: Kui kasutaja tühistab viiba või API kutse ebaõnnestub mis tahes põhjusel (nt toetamata brauseris), siis ja ainult siis peaksite kuvama täieliku, traditsioonilise kasutajanime/parooli vormi.

Näide: Ühtne `get()` väljakutse

            async function unifiedSignIn() {
  try {
    // Note: These `publicKey` and `federated` options would come from your server
    const publicKeyOptions = await fetch('/api/webauthn/login-options').then(r => r.json());
    // ... (buffer decoding logic here) ...

    const cred = await navigator.credentials.get({
      password: true,
      publicKey: publicKeyOptions,
      federated: {
        providers: ['https://idp.example.com']
      },
      // 'optional' prevents an error if the user has no credentials
      mediation: 'optional' 
    });

    if (!cred) {
      console.log('User cancelled or no credentials. Showing form.');
      showTraditionalLoginForm();
      return;
    }

    // Handle the credential based on its type
    if (cred instanceof PasswordCredential) {
      console.log('Handling password credential...');
      await serverLogin(cred.id, cred.password);
    } else if (cred instanceof PublicKeyCredential) {
      console.log('Handling PublicKeyCredential (Passkey)...');
      await serverLoginWithPasskey(cred);
    } else if (cred instanceof FederatedCredential) {
      console.log('Handling FederatedCredential (FedCM)...');
      await serverLoginWithToken(cred.token, cred.provider);
    }

  } catch (err) {
    console.error('Unified sign-in error:', err);
    showTraditionalLoginForm(); // Fallback on any error
  }
}

            

              
                Copy
              
            
          

Globaalsed kaalutlused ja parimad praktikad

Rakendades neid kaasaegseid autentimisvooge globaalsele publikule, pidage meeles järgmist:

• Brauseri tugi: Kontrollige alati iga API brauseriühilduvust saitidelt nagu caniuse.com. Pakkuge vanemate brauserite kasutajatele kindlaid tagavaralahendusi, et tagada, et kedagi ei jäeta välja.
• Serveripoolne valideerimine on möödapääsmatu: Esiliides on ebausaldusväärne keskkond. Kõik kliendilt saadud mandaadid, märgid ja kinnitused peavad olema serveris rangelt valideeritud enne seansi loomist. Need API-d parandavad esiliidese kasutajakogemust; need ei asenda taustaprogrammi turvalisust.
• Kasutajate harimine: Mõisted nagu pääsmevõtmed on paljudele kasutajatele uued. Kasutage selget ja lihtsat keelt. Kaaluge tööriistavihjete või linkide lisamist lühikestele selgitustele (nt "Mis on pääsmevõti?"), et juhendada kasutajaid protsessi läbimisel ja luua usaldust.
• Rahvusvahelistamine (i18n): Kuigi brauseri natiivsed kasutajaliidesed on tavaliselt brauseri tootja poolt lokaliseeritud, tuleb teie lisatud kohandatud tekstid, veateated või juhised sihtrühmade jaoks korralikult tõlkida.
• Juurdepääsetavus (a11y): Kui loote nende voogude käivitamiseks kohandatud kasutajaliidese elemente (nagu kohandatud nupud), veenduge, et need oleksid täielikult juurdepääsetavad, koos korralike ARIA atribuutide, fookuse olekute ja klaviatuurinavigatsiooni toega.

Kokkuvõte: Tulevik on käes

Aeg, mil toetuti ainult tülikatele ja ebaturvalistele paroolivormidele, on lõppemas. Esiliidese arendajatena on meil nüüd võimas komplekt brauseri API-sid, mis võimaldavad meil luua autentimiskogemusi, mis on samaaegselt turvalisemad, privaatsemad ja tunduvalt kasutajasõbralikumad.

Võttes omaks Mandaadihalduse API kui ühtse sisenemispunkti, saame oma rakendusi progressiivselt täiustada. Saame pakkuda ühe puutega parooliga sisselogimise mugavust, WebAuthn-i ja pääsmevõtmete raudkindlat turvalisust ning FedCM-i privaatsusele keskendunud lihtsust. Teekond paroolidest eemale on maraton, mitte sprint, kuid tööriistad selle tuleviku ehitamise alustamiseks on meile täna kättesaadavad. Nende kaasaegsete standardite kasutuselevõtuga saame mitte ainult rõõmustada oma kasutajaid, vaid muuta ka veebi kõigi jaoks turvalisemaks paigaks.